At this time, I'm leaning towards Option 2 for a couple of reasons.

First, I found this quite compelling:

This decouples our data model more from MARC where we seem to have modeled a set of data to match 260/264 in a way that doesn't seem to map to our other sources

Second, when you extend that thinking further, though I'm confident we will encounter publisher dates, it's more likely that we'd want those dates when already in the context (i.e. facet filter) of thinking about dates. This, as opposed to rooting around in an object for them.

This might suggest a somewhat general pattern where some fields in TIMDEX benefit from having kind or other kinds of qualifiers, e.g. Dates and Locations. We may have date and location information for other descriptive components -- like Publisher -- but we often don't need to know all that at once. Storing a date@kind=publisher and location@kind=publisher, as long as the kind values are sensible and controlled (which we could enforce in Transmog), makes that information more where you need and expect it.

FWIW, this might suggest that Option 1 (array of complex publisher objects) aligns more closely with MODS: https://www.loc.gov/standards/mods/userguide/origininfo.html.

In the MODS schema, the <origininfo> parent element has child elements for place, publisher, date, location, etc.

To me, the difference between Option 1 and 2 feels like it gets at a bigger data model decision: do we store subjects/dates/locations under complex objects like publishers, contributors, etc.? or do we store those as simple arrays of strings, and then qualify any subects/dates/locations with a @kind qualifier and store them in subjects/dates/locations/etc.?

The decision for this ADR, feels like it would set precedence for that going forward, as I'm not seeing this situation in any other fields (complex objects with child dates/locations).

I think that I continue to support Option 2, and lean into that model:

• simple, top level arrays of strings where it makes sense
• any subjects / dates / locations get routed to those fields, with meaningful and ideally somewhat controlled @kind qualifiers

To me, this is more flexibile in the long run. As we encounter subjects / dates / locations that should be in the record, but don't fall under a complex object, we can continue to slot them into those fields, but ensure (and document) what the @kind qualifiers are.

Option 2 sounds good to me, especially after looking into all-current index on OpenSearch (shared in this comment. Approved on my end once decision is officially written into the ADR!

In case any further coalescence is needed, I support Option 2 at this point, if not just for flexibility and ease of use.

@matt-bernhardt great question. Yes, Option 1 provides an ability Option 2 does not that we hadn't stated (and I hadn't noticed). Namely, if there is value in keeping the publisher related date together when there are multiple publishers, Option 1 provides that in a way that Option 2 does not.

Based on how infrequently there appear to be multiple real publishers (versus currently a lot of the extra publishers are actually just years inserted into the array), this may not be a concern. However, it should be noted as a distinct feature difference between the two options for sure and noted in the consequences section if we choose the one that would lose this ability to keep these fields together in an object.

Agreed, that @matt-bernhardt's observation is an important one, namely that we decouple the publisher name from the its dates/locations and lose that tether.

Maybe this is not problematic if we continue to view these TIMDEX records through a discovery lens, and not a canonical record lens. And, potentially even more accurate when we consider the behavior of facets.

Consider this situation with two publishers:

1. "Great Writings; Bend, OR; 1980"
2. "Amazon Reprints, Seattle, WA; 2020"
3. "Ebooks Inc., Believed to be 2023 but records are hazy"

If this record comes up in a search, and a user clicks the publisher facet for "Great Writings", if we tightly couple the publisher name + location + date, we'd lose the location "Seattle, WA" and the date "2020" in the facets. However, I'd float those facet values are still relevant to the record, as they are part of its metadata in its totality.

The flipside -- and what I assume is the concern raised above -- is that by decoupling them, we would lose the ability to look directly at this TIMDEX record and know:

1. For the "Great Writings" publisher, the date was 1980 and the location was Bend, OR
2. For the "Amazon Reprints" publisher, the date was 2020 and the location was Seattle, WA

I hesitate to suggest it... but what if we combined Option 1 & 2?

{
  "publishers": [
    {
      "name": "Great Writings",
      "date": "1930",   <----- use original string
      "location": "Bend, OR"
    },
    {
      "name": "Amazon Reprints",
      "date": "2020",   <----- use original string
      "location": "Seattle, WA"
    },
    {
      "name": "Ebooks Inc.",
      "date": "Believed to be 2023 but records are hazy"   <----- use original string
    }
  ],
  "date": [
    {
      "kind": "Published",
      "value": "1980-01-01"   <----- parsed as true dates, with an eye towards this desired state
    },
    {
      "kind": "Published",
      "value": "2020-01-01"   <----- parsed as true dates, with an eye towards this desired state
    }
  ],
  "locations": [
    {
      "kind": "Published",
      "value": "Bend, OR"
    },
    {
      "kind": "Published",
      "value": "Seattle, WA"
    }
  ]
}

In this scenario, we'd get:

• accurate facets; no loss of information when one publisher identified
• publisher dates/locations slot into dates and locations for ease of use there
  • furthermore, they are parsed and normalized according to those fields
• for the messy "Ebooks Inc." entry, we maintain the original strings, but we just skip extracting and normalizing dates from it

There is duplication of information, but we'ev also normalized and filtered out bad values while still retaining the original which may have some meaning.

It also might be less jarring to see this in the context of other fields. If the pattern is: store complex objects, but attempt to extract meaningful dates / subjects / locations from it and store in those respective fields, then maybe it doesn't seem as unusual?

Lastly, from a Transmogrifier POV, we could focus on writing complex Publisher objects, then have shared methods and normalization logic across all sources that attempt to parse out distinct subjects, dates, locations, etc.

Just food for thought!

Maybe this is not problematic if we continue to view these TIMDEX records through a discovery lens, and not a canonical record lens.

I still think discovery is the most appropriate lens to view TIMDEX and combining 1 & 2 feels like it's introducing a lot of complexity for accuracy in a likely rare occurrence of multiple legitimate publishers

More comments forthcoming, but I did want to correct a mistake in my comment from last week.

Specifically, that when selecting a facet value, we don't "lose" the other facet values from that particular record. See this example of selecting "Polygon data" as a facet value, but because the document contains other values for "Content Type", they still show up:

I think this is an important clarification, as neither Option 1 or 2 result in the behavior I had suggested above.

@JPrevost, @matt-bernhardt, @ehanson8, @jazairi, @jonavellecuerdo - an "Option 3" has been added per this commit that sketches a combination of Option 1 and Option 2.

Matt's observation about Option 2 losing context between publisher names and dates/locations felt like an important one. Personally, this felt like a deal breaker for Option 2 for me.

However, I feel Option 1 may continue to propagate some pain points we are feeling in the TimdexRecord / Opensearch / GraphQL / Search UI / Item Page UI relationships where we are required to dig into complex objects for aggregations. This alone may not be technically problematic, but it could be brittle in the longer term (see example in Option 3 where "Publisher" or "Date" sections start to drift between the search UI filters and the item page representation).

It's hard to succinctly summarize, and might be beyond the scope of this ADR to some degree, but to me Option 3 represents a pattern that could be applied going forward: store complex objects to preserve context, but also extract subjects / dates / locations for ease of use and consistency of aggregation and item viewing.

Perhaps Option 3 is not ultimately what we want, but hoping it can help clarify the strenghts and weaknesses of the current Options 1 and 2.

At this time, my vote would be for Option 3.

Maybe this is not problematic if we continue to view these TIMDEX records through a discovery lens, and not a canonical record lens.

I still think discovery is the most appropriate lens to view TIMDEX and combining 1 & 2 feels like it's introducing a lot of complexity for accuracy in a likely rare occurrence of multiple legitimate publishers

From this mini data dive, looks like we might have a fairly sizable number of legitimate publishers for Alma?

I'd also propose that storing a complex object + extracting dates and locations really is the same complexity as option #2, we're just storing a bit more than the publisher name in the final record. The actual parsing and movement through the data should be the same.

Furthermore, as noted in Option 3, I think it's possible we could have each source just focus on creation of the object, and have a global process extract dates and locations from the publisher objects, for all sources. But could discuss that implementation detail separately.

I like Option 3. I think lines 165-168 of the ADR summarize it really well. I feel it benefits users by preventing information loss, and it also benefits developers by easing navigation of the data model.

As a side note, Aardvark.dct_issue_s could be updated to use kind="Publication date" (instead of "Issued") to follow the timdex.Date derivations for other transformers.

As a side note, Aardvark.dct_issue_s could be updated to use kind="Publication date" (instead of "Issued") to follow the timdex.Date derivations for other transformers.

Agreed @jonavellecuerdo about looking for opportunities to standardize the kind values we use. To the degree that we "extract" data from other parts of a record and store them as Dates / Subjects / Locations, it increases the value in standardizing the kind qualifiers we use.

It may be out of scope for implementing the final decision of this particular ADR, but a follow-up ADR at some point around normalizing kind values would be a great one.

I'm fine with Option 3 as well. Standardizing kind values is something we've wanted to do but just never got around to it, this would be good to prioritize as we go down this road